IBIS Macromodel Task Group Meeting date: 31 May 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: C_comp Improvements: - Randy: I've started with the last revision of this BIRD draft, approximately a year old, and I'm converting it to the new BIRD template. - The first thing in the new template is the Solution Requirements table. - I've drafted the rough text of the entries in the Solution Requirements table, and I wanted to discuss the requirements with the group and come to agreement on them before I proceed. - [Sharing Solution Requirements table from new BIRD draft] - Requirement #1: Allow an IBIS-ISS subcircuit or Touchstone file to be used as a C_comp model. - Note #1: Up to three models should be allowed to cover typ/min/max corners. Define how they align with corners. - Discussion: Arpad asked if the Note indeed meant no-more-than three. Randy said the intention was that you might have one subcircuit (or Touchstone file) for each corner, or one that served for all corners, but that three would be the max. - Requirement #2: Define the terminals of the C_comp model including references, signal (both internal and external to allow a series R model) and a receiver terminal for probing the input buffer. - Note #2: Terminals for single-ended and differential models should be defined. - Discussion: Mike asked if probing the input buffer were optional or mandatory? Randy said the model could include this terminal and the EDA tool could optionally use it. He said the reason for specifying that terminal was that one may have some series R or C filtering between the pad and the actual input receiver, and that Micron had found it very useful to be able to probe that node. Bob noted that a series C could cause problems for many tools, and Randy agreed and said we should restrict that series element to a resistance [change already made in the text above]. Randy also said the Note might actually be considered a separate requirement. Arpad agreed and said we might need to clarify pseudo vs. true differential. Arpad noted that true differential is only available with [External Model]. Bob said we might require that this works with or without External Model. Walter noted that true differential is really only available with [External Model], in which case C_comp or this new C_comp model would not be used anyway. It would all be embedded in the [External Model]. - Randy: [Sharing C_Comp Model Using IBIS-ISS draft 6 (posted April 7, 2015)] - Discussion: Randy briefly reviewed Figure Y in order to discuss the internal and input buffer terminals (A_signal_I and A_receive). Walter asked if this figure meant that for an I/O the A_receive section just goes into the [POWER Clamp] and [GND Clamp] curves, and the A_signal_I section goes into the [Pullup] and [Pulldown] curves? Walter said his interpretation of the figure was that the receiver is always receiving, and its load would be captured in the clamping tables. The driver aspect would be completely switched off if the buffer weren't driving, and that aspect would be captured in the [Pullup] and [Pulldown] tables. Bob said that his interpretation was that driver mode was represented by the top buffer in the figure, and the receiver part was disconnected when driving, so the driver portion also considered the clamping tables. The receiver portion is switched in during receive mode, but the generalized C_comp model can support a different path from the signal pad to the receiver. He said the A_receive was a new terminal not in the current multilingual. Arpad stated that it didn't necessarily require a new terminal because at simulation time the device is either in driver mode or receiver mode (can't switch during the simulation) so the node would either be one or the other. Bob agreed that this was possible if the generalized C_comp model had a way to switch between driver and receiver modes. Randy pointed out that a series element in the path to A_signal_I was the result of an on-die interconnect, where the series element in the path to A_receive might be there for intentional filtering. Arpad noted that we didn't have to solve the actual implementation issues (new terminal vs. two separate C_comp models for driver or receiver mode) at this point. - Requirement #3: Explain handling of the reference for Touchstone files. - Note #3: [none] - Discussion: Radek and Mike recommended this be changed to the general statement shown above, and said this can ultimately rely on the solution being worked out in the interconnect meetings. - Requirement #4: Define how parameters can be instantiated and passed into the IBIS-ISS subcircuits for each of the typ/min/max corners. - Note #4: Parameters should be single values that can be passed into either the typ, min or max corner subcircuit. Parameters are not meant to define ranges. - Discussion: Randy noted that the interconnect task group allowed only single valued parameters to be passed into a subcircuit. For this C_comp proposal we need a way to pass parameters into one of three subcircuits (corners), but that his intention is that those parameters are still single valued and not ranges, etc. Bob pointed out that we would need to carefully define how the C_comp subcircuit corners align with the typ/min/max model corners. Randy agreed and added this definition of alignment to Note #1. Mike noted that we might want to require that the three subcircuits for the corners all take the same parameters, since we probably want to avoid a case where the typ subcircuit takes a param called typ_ABC while the max subcircuit takes one called max_ABC. - Requirement #5: Explain hierarchy of the new C_comp model with existing keywords including [C Comp Corner] or any other C_comp* models. - Note #5: The new C_comp model should override other C_comp models. May need to explain how a simulator could use traditional C_comp* values for K-T curve generation. - Discussion: Randy said this requirement captured the need to describe how a simulator would actually use this new C_comp model. For example, we might adopt Walter's suggestion and describe how legacy C_comp is used only to generate the K(t) curves, and then the new C_comp model is inserted at simulation time. Bob expressed concerns about the alignment of various C_comp parameters and or the [C Comp Corner] parameters. Walter said he thought we would need to require the use of [C Comp Corner] because every v(t) curve has to be compensated for C_comp, and we need to know the right C_comp for each corner. Bob agreed. He noted that some tools made assumptions about how to choose standard C_comp parameters to match various corners, but that would open up a whole separate set of issues. Referencing Question: - Discussion: Walter reviewed a brief email he had sent to the ATM list. We have three voltages VDD, VSS (the rails) and V at the I/O (IO) all relative to some simulator reference node. Does everyone agree that the operation of the buffer is only a function of two of the following three voltages?: 1. VDD - VSS 2. VDD - IO 3. VSS - IO The third can be derived given any two of them. Arpad said he tended to agree with this statement, since we have two I/V curves based on VDD-IO and IO-VSS. Radek felt the question was too simplified since it said nothing of the load. Arpad asked what the exact purpose of asking the question was. Walter said he would send out another email and rephrase the question and explain its intent. - Bob: Motion to adjourn. - Mike: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 7 June 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives